SLO サービスレベル目標

SLOは単なるデータである

導く指針であって何かを要求するものではない、厳格なルールがあるものでもない。

新しいデータセットを自ら提供することこそ最終的な目的

SLOはプロセスてあってプロジェクトではない

OKR等に結びつく成果目標ではない

全てを反復する

必要に応じてSLOは変更できる

全て人に関わる

選択したSLOの目標値や過程において周りの人が不満や困惑している場合は一度立ち止まる。SLOはユーザーやエンジニア、ビジネスに対して至福をもたらすものであって目標値を達成すればよいというものではない。

100%は不要である

信頼性にはコストがかかる

ユーザーにとって必要とする程度の信頼性を達成するべきである

→どうやってユーザーが必要とする信頼性の基準を知る？

→この唯一の答えは存在しない。SLOに基づくアプローチ(データを見ること)を一つの手段としてどの程度の信頼性が必要なのかを議論する

→ユーザーの立場になる、サービスに必要としているものはなにか、どの頻度でパフォーマンスの発揮を期待しているのか。

意味のあるSLI

ユーザーの観点から見てサービスがどの用に動作しているかを示すメトリクス

→サービスの信頼性をどうやって計測しているかを開示する。

要求を満たすような努力の姿勢や目指す方向性を伝え続ける

サービスが何を実行するべきではない、ユーザーがそのサービスで何を実行する必要があるのかを考える。

→他の人も巻き込む

アップタイム

可用性

信頼性

メトリクスは真であるかないかを判断できるようなものであるべき

障害とはサービスが期待されている動作をじっこうしていないとき

問題になるのは障害が頻繁に発生したり、長く続いたりする場合

信頼性が高すぎるゆえの問題

→運用負荷不足による修復方法の学習ができない

エラーバジェットによって障害の発生の許容と学習の機会のバランスを定義する

適切なSLOの数

→多重検定問題

議論するデータポイントが多すぎると信頼性の状態を伝えるのが難しくなる

サービスの依存対象を知る

強い依存対象

弱い依存対象

実験とカオスエンジニアリング

適切なSLIの指標かどうかを計測するのに効果的

負荷テストおよびストレステスト

ブラックホール演習

エラーバジェットの計測

ウィンドウ、状態、ポリシーを文書化し検索可能な状態にする

イベントベース

時間が経過する中で悪いイベントが?%なら許容できると考える

時間ベース

時間が経過する中で悪い分数(秒数)が?なら許容できると考える

どちらも含んでいて問題ない。ダッシュボードにどちらも含めるとか

それぞれ長所短所がある

イベントベース:カーディナりてぃが高いレベルに達していないと問題が発生する可能性がある。レイテンシーの計測といった概念に対して当てはめやすい。

時間ベース:計算が複雑、でもわかりやすい(ex. エラーバジェットが尽きるまで今月は不良な運用がさらに⚪︎分可能です。可溶性の計測やデータ処理のパイプラインのエンドツーエンドの状態といった概念に対して直感的

→組み合わせて使っても良い

イベントベースのアプローチ:監視

時間ベースのアプローチ:人による意思決定とレポート作成

カレンダーウィンドウによるエラーバジェット枯渇問題

ある月にエラーバジェットを使い果たす

ポリシーでは新機能のリリースを停止してサービスの改善に集中するとしている

しかし実態はバックグラウンドで新機能を開発しており、本番環境に送り出していないだけだった。

そこで次の月になり新しい機能のリリースをするとすぐにエラーバジェットを超過してしまった

するとまた機能のリリースは凍結....

意思決定

基本的な考え方は単純

エラーバジェットが余った→より機能をリリース

超過した→信頼性に集中

信頼性を高める必要があるかどうかを判断するための材料

エラーバジェットポリシー

エラーバジェットの消費レベルにチームがどう対応するのかを示すルールとガイドライン

しなければならない、しても良い、するべきである、する必要がある

RFC2119

いつ対策を行うかを判断するためにバジェットを消費している速さを計算する

優れたエラーバジェットポリシーはそのポリシーがなぜ選ばれたのかを説明する文言が含まれている

ex)エラーバジェットを80%消費するまでは対策を行う必要がない←なぜ？

検討(再検討)の日付も残す

理由の簡単な根拠

段階

SLIを使用してサービスについて考える

ユーザーにとってどの程度の信頼性が必要なのかを考える

時間経過の中で目標値に対してどの程度実行したかを計算する

エラーバジェットの状況を使用して議論を行う

疑問

そもそものこの時間ウィンドウの選択ってリリースサイクルにめちゃくちゃ依存しないか？

同意の獲得

もとめられることは、ユーザーの関心を優先した選択の是非を議論すること。

かなり忍耐強い説得が必要。

利害関係者

開発チーム

SLOは時間の経過とともに信頼性のみではなく機能のリリース速度も向上させる。

SLOは開発担当者がより多くのリスクをとり、従わなければならないリリースの制約を少なくする。

エラーバジェットポリシーの原理に基づく実践によって、人々はより優れたソフトウェアエンジニアになれる。(ユーザーの現実に基づいた迅速のフィードバックループが形成されている)

製品チーム

製品に組み込む機能と、その中での優先順位を決定する責任を持っていると仮定

製品が使用できなかったり動作エラーを発生したりして期待通りの動作をしない場合、ユーザーはその製品を信じなくなる。

なので信頼性は製品要求仕様書に含めるべきである。

SLIとユーザージャーニーの間には強力な対応関係がある。SLIはPRDに記述されたユーザージャーニが監視され計測され確認する手段である。

SLOはリリースサイクルから多くの軋轢を除去するので結果的に製品の機能のリリース速度を速める。

運用チーム

担当するシステムからの通知を受け取れるページャーを持ち歩く全ての人と定義。

SLOとエラーバジェットポリシーを使用すると、運用担当者は開発担当者と対等な立場で仕事ができる。

デプロイの軋轢を排除できる、システムの安定性の一端を開発チームがえるため。

法務

リスクの最小化に責任を持つ

テスト済みのSLOが存在しない限り、法務が書いたSLAがただしいかは分からない。

クレームが発生する前にアラートを受け取れる。

経営幹部

完璧であることは不可能であり、同時に逆効果であることを理解してもらう。

失敗を犯さないように努力するのでは中、失敗しても早く気づいてエラーの影響が広がらないように気を配るほうが会社としては良い結果になる

活動方針

開発および運用

製品

経営幹部

法務

教訓

多すぎないこと、はやすぎないこと

一つの障害ドメイン(相互に緊密に依存し合って同時に障害を発生させる単位からはじめる

説得の人数や維持が楽になり始めやすい

少ないほうが豊か

一つのエラーバジェットポリシーめ始める

レビューは早いうちに

透明性を持つ

計測

設計目標

よくある事例

レイテンシ重視のリクエスト処理

→エラー比率のレートとレイテンシP99orP95

ユーザーがシステムにどのような動作を望んでいるかが回答として得られるような質問を行う。